REMARKS 


No claims have been amended, added or cancelled. Claims 1-20 remain pending 
in the application. Reconsideration is respectfully requested in light of the following 
remarks. 

Section 103(a) Rejection : 

The Examiner rejected claims 1, 12 and 20 under 35 U.S..C. § 103(a) as being 
unpatentable over Aldred et al. (U.S. Patent 5,719,942) (hereinafter "Aldred") in view of 
Official Notice, claims 2-6, 8-11, 13-17 and 19 as being unpatentable over Aldred in 
view of Simonoff et al. (U.S. Patent 6,005,568) (hereinafter "Simonoff '), and claims 7 
and 18 as being unpatentable over Aldred and Simonoff, and in further view of Jalili et al. 
(U.S. Patent 5,423,042) (hereinafter "Jalili"). Applicants respectfully traverse these 
rejections for at least the reasons presented below. 

Regarding claim 1, contrary to the Examiner's assertion, Aldred, in view of the 
Examiner's Official Notice does not teach or suggest a first application launching a 
second application , where the launching of the second application includes the first 
application passing an event port number and a command port number to the second 
application . In contrast, Aldred specifically teaches the use of support system software 
together with call manager applications to establish, configure, and manage 
communication channels between applications, especially between applications executing 
on different hardware nodes (Abstract; column 1, lines 52-60). Aldred teaches that 
groups of applications communicate by participating in named sharing sets. Aldred's call 
managers coordinate, monitor and manage the various share sets of applications. Aldred 
also teaches a support system and a software API through which applications interact 
with the call managers. Aldred's API includes functions for initiating and configuring 
communication between shared applications via channels and signals. 
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The Examiner cites various portions of Aldred (column 5, lines 51-63; column 6, 
lines 39-49; column 7, lines 33-62; column 12, lines 57-61; and column 36, lines 3-52) 
that describe Aldred's channels and share sets. However, none of these cited passages 
describes passing event port numbers and command port numbers to an application as 
part of launching that application. Instead, Aldred teaches a manner and method of 
initializing and configuring communication channels between applications that does not 
include passing event port numbers and command port numbers as part of launching an 
application. Aldred explains the benefits of using the support system software when 
establishing and configuring communications channels. For example, relying upon call 
managers and the support system software allows applications to be "aware" of, and to 
use, Aldred's system while avoiding the need to be involved in "call set-up or tear- 
down." Aldred teaches the benefit of providing clear separation of call management and 
application programming (Aldred, column 26, lines 62-67). Aldred also states, "in order 
for an application instance to be allowed to communicate with the system, it must 
identify itself by issuing a register_app call" (column 35, lines 48-67). Aldred also 
teaches, "it is up to the launched application to use [the] register_app [function] to fully 
identify itself to the system" (column 36, lines 21-55). Aldred describes that adding a 
port to a channel includes a request from one application, which is sent via the support 
system as an unsolicited event to a second application, and a confirmation (or error) 
response routed back to the first application as a confirm event. (Aldred, column 24, lines 
39-51). Additionally, one of the benefits of Aldred's share sets, call managers and 
support system software is that data may be communicated across heterogeneous 
networks using passive nodes to route data between an application on one node and 
another application on another node (Aldred, column 2, lines 19-50; column 5, lines 41- 
50; column 19, lines 24-48). Nowhere does Aldred describe passing event port numbers 
and command port numbers to an application as part of launching that application. 

The Examiner also cites column 11, lines 27-39 and column 29, lines 8-19, where 
Aldred describes launching applications and refers to Aldred's "launch_app" API 
command. However, Aldred's launch_app function is used by applications to interact 
with, and request support services from, Aldred's call managers (see, Aldred, column 4, 
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lines 27-43). Thus, an application wishing to launch another application uses the 
launch_app function to communicate the request to a call manager. The call manager 
forwards the request to a call manager executing on the appropriate node of Aldred's 
system. The second call manager may then launch the requested application (Aldred, 
column 5, lines 51-63). The fact that Aldred includes a mechanism to launch applications 
does not teach or suggest passing an event port number and a command port number as 
part of launching an application. Nowhere does Aldred describe passing event port 
numbers and command port numbers as part of launching an application. In contrast, 
Aldred teaches that an application may issue a launch_app command and may be 
returned a limited use handle to the launched application that is "only valid in very 
restricted circumstances until the launched application has registered with the support 
system" (emphasis added, column 11, lines 34-36). Thus, as noted above, Aldred teaches 
that ports, and therefore event port numbers and command port numbers, are only 
configured after an application has registered with the support system. 

The Examiner, in the Response to Arguments section, argues that it would be 
obvious to include an event port number and a command port number as parameters 
when launching an application in Aldred's system. The Examiner's assertion is 
completely unsupported by the teachings of the cited art. In fact, Aldred actually teaches 
away from one application launching another application and passing event port numbers 
and command port numbers as part of launching the other application. As described 
above, Aldred's system already includes a very specific mechanism to initiate and 
configure ports and channels between applications that specifically does not include 
passing event port numbers and command port numbers as part of launching applications. 
Aldred clearly teaches the benefits of an application first registering with a call manager 
and joining a share set before initiating or configuring channels and ports. Rather than 
providing any motivation to modify Aldred's system to pass event port numbers and 
command port numbers as part of one application launching another application, Aldred 
teaches away from one application launching another application and passing event port 
numbers and command port numbers as part of launching the other application. 
Furthermore, it would not make sense to modify Aldred to bypass the share sets that are 
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central to Aldred's system by passing event port numbers and command port numbers as 
part of launching applications. Such a modification would not only be contrary to 
Aldred's specific teachings, it would remove the specific benefits of Aldred's sharing 
sets, call managers, and support system software. 

Moreover, modifying Aldred's system to include passing an event port number 
and a command port number to an application as part of launching that application would 
change the principle of operation of Aldred's system. Aldred system relies upon 
applications registering and utilizing both the call managers and the support system 
software via Aldred's API to properly initiate and configure communications between 
applications. Bypassing this system to send event port numbers and command port 
numbers to applications, as part of launching those applications, would bypass Aldred's 
sharing set concept, which is essential to the operation of his system, and thus change 
Aldred's principle of operation. As discussed in § 2143.01 of the M.P.E.P, a rejection 
based on a modification that changes the principle of operation of a reference is 
improper. 

The Examiner also states that "it is inherent to Aldred that the port numbers are 
stored in a memory accessible to both applications because Aldred discloses being able to 
alter ports and channels after having been initially established" and cites column 8, lines 
49-55 and column 12, lines 36-42 of Aldred. The first cited passage mentions that certain 
characteristics of ports and channels can be changed after they have been initially 
established and the second cited passage describes that a string of user information may 
be passed as a parameter to an API call to a target application. However, neither of the 
cited passages teaches anything about storing port numbers in memory accessible to two 
applications. Instead, Aldred teaches the use off change_port and change_channel API 
commands, as well as application events to modify the characteristics of ports and 
channels (Aldred, column 29, lines 33-41, and column 32, lines 40-67). Thus, rather than ' 
teaching that port numbers are stored in a memory accessible to both applications to 
support altering ports and channels, as the Examiner contends, Aldred specifically 
teaches API command and events to communicate changed port and channel 
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characteristics. Also, the port numbers in Aldred are not passed as part of launching an 
application. Moreover, Aldred's system is directed to communication channels between 
different nodes, including intermediate nodes, on a network (Aldred, Abstract, and 
column 1, lines 52-60). Aldred teaches that a node is usually a dedicated programmable 
workstation (column 4, lines 62-67). Thus, it would not make sense for Aldred to store 
port numbers in a memory associated with two applications, since Aldred supports 
communication between applications on separate hardware nodes. 

Additionally, the Examiner takes official notice that "it would be obvious to one 
of ordinary skill in the art to store the port numbers that are passed between Aldred's 
sending application to the receiving application." Pursuant to M.P.E.P. § 2144.03, 
Applicant traverses the Examiner's taking of official notice. As shown above, Aldred 
does not pass command and port numbers between applications when launching an 
application and thus does not teach or suggest storing port numbers passed between 
applications as part of launching one of the applications. Applicants assert that it is not 
well known in the prior art to store port numbers passed between applications as part of 
launching an application. Pursuant to M.P.E.P. § 2144.03, "the examiner must provide 
documentary evidence in the next Office action if the rejection is to be maintained. See 
also 37 CFR 1.104(c)(2), (d)(2) and In re Zurko, 258 F.3d 1379, 1386 (Fed. Cir. 2001). 

Thus, for at least the reasons presented below, the rejection of claim 1 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
also apply to claims 12 and 20. 

Regarding claim 5, Aldred in view of the Examiner's Official Notice, in further 
view of Simonoff does not teach or suggest passing a function reference value through 
the command port connection. The Examiner cites column 24, lines 52-61 of Aldred. 
However, this portion of Aldred is referring to how applications can make asynchronous 
calls to Aldred's support system software API by including a reference identifier 
allowing the application to issue command to obtain the status of, or to cancel, an 
asynchronous API call. The cited passage does not describe passing a function reference 
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value through a command port connection, as suggested by the Examiner. The reference 
identifier mentioned in the cited passage is not a function reference value that is sent 
through a command port connection. Instead, it is merely an identifier to allow a calling 
application to check on the status of an asynchronous API call. The Examiner does not 
rely on Simonoff in the rejection of claim 5. Nor does Simonoff overcome Aldred's 
failure to teach or suggest passing a function reference value through a command port 
connection. Thus, the rejection of claim 5 is not supported by the prior art and removal 
thereof is respectfully requested. Similar remarks apply to claim 16. 

Regarding claim 6, Aldred in view of the Examiner's Official Notice, in further 
view of Simonoff does not teach or suggest passing a function parameter through the 
command port connection. The Examiner cites column 24, lines 39-42 of Aldred. 
However, this passage of Aldred describes how Aldred's system handles an application's 
request for a service. Specifically, Aldred teaches that an application requests a service 
and supplies the appropriate parameters. Another application, supplying the service, is 
made aware of the request through an "unsolicited event which appears as an indication" 
to the second application. The response from the second application is routing back to 
the requesting application as a "confirm event." The cited passage does not mention 
passing a function parameter through a command port connection, but instead teaches the 
use of unsolicited events to request a service and to deliver responses. Elsewhere 
(column 7, lines 44-62) Aldred teaches three different types of port connections: event, 
command and null ports. The passage cited by the Examiner in the rejection of claim 6 
clearly refers to issuing events via event ports. The cited passage does not mention any 
command port connection. Thus, the rejection of claim 6 is not supported by the prior art 
and removal thereof is respectfully requested. Similar remarks also apply to claim 17. 

Applicant also asserts that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the rejection has been shown to be 
unsupported for the independent claims, a further discussion of the dependent claims is 
not necessary at this time. 
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CONCLUSION 


Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
78901/RCK. 

Also enclosed herewith are the following items: 
13 Return Receipt Postcard 
|~1 Petition for Extension of Time 
I | Notice of Change of Address 
□ Other: 


Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: September 12. 2005 
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Respectfully submitted, 



Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 


